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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 

® Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen 

aufweisendes Managementnetz 
® Die Erfindung geht davon aus, dafc fur einen Alarmda- 
tenabgleich zwischen einem Agent (AG) einer Manage- 
mentebene (B, C) und zumindest einem Manager (MA1, 
MA2) einer nachsthoheren Managementebene (A, B) die 
Alarmdaten aktiver Alarme ubertragen werden. Daruber 
hinaus werden von einem Manager (MA1, MA2) eine oder 
mehrere Anforderungsnachrichten (repAA) zum Ubermit- 
teln der Alarmdaten an den Agent (AG) gesendet, sowie 
Korrelationsinformationen (alaAH, aliNI) fur eine Zuord- 
nung der jeweiligen Anforderung zu den vom Agent (AG) 
nachfolgend gesendeten Nachrichten (aINO) empfangen. 
Erfindungsgemafc wird von dem Manager (MA1, MA2) 
der Alarmdatenabgleich abhangig von zumindest einem 
zum Agent gesendeten Parameter gesteuert. Durch den 
■ Erfindungsgegenstand ist der Alarmdatenabgleich fur 
den Manager gegenuber der Basisfunktionalitat - Verwen- 
dung der Korrelationsinformationen - parametrisierbar, d. 
h. nicht mehr alle aktiven Alarme mussen zwangslaufig 
vom Agent gesendet werden, sondern nur die durch den 
ubermittelten Parameter naher definierten. Daraus ergibt 
sich eine optimale Nutzung der Ubertragungsressourcen 
auf der Schnittstelle der Agent-Manager-Beziehung sowie 
ein schnellstmogliches Bereitstellen nur der vom Mana- 
ger gewunschten Alarmdaten durch den Agent. 
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Beschreibung 



Die Erfindung betrifft ein Verfahren sowie ein entspre- 
chendes Kommunikationssyslem zur Behandlung von Alar- 
men durch ein mehrere Managementebenen aufweisendes 5 
Managementnetz, wobei fur einen Alarmdatenabgleich zwi- 
schen einem Agent einer Managementebene und zumindest 
einem Manager einer nachsthoheren Managementebene die 
Alarmdaten aktiver Alarme ubenragen werden. 

Die Ptinzipien eines Managementnetzes, die auch als 10 
TMN-Prinzipien (Telecommunications Management Net- 
work) bezeichnet werden, definieren mehrere Management- 
ebenen fur das Management eines Kommunikationssystems 
- beispielsweise eines Mobil-Kommunikationssystems -, 
wobei jede Ebene eine doppelte Funktion hat Im managen- 15 
den System hat jede Ebene auBer der untersten eine Mana- 
ger- Funktion fur die darunterliegende Ebene. Im gemanag- 
tcn System hat jede Ebene auBcr der obcrstcn cine Agcntcn- 
Funktion fur die nachsthohere Ebene. 

Das Fehlermanagement ("Fault Management") ist ein 20 
wichtigerTeil des TMN-Managements. Grundsatzlich spielt 
hier der Agent die aktive Rolle, indem er Fehler der eigenen 
Managementebene rechtzeitig und genau erkennt und an 
den Manager der nachsthoheren Ebene als Alarme ubertragt. 
Die Ubertragung von Alarmdaten voin Agent zum Manager 25 
ist unkritisch, solange der Kommunikationsmechanismus 
zwischen diesen Systemen nicht gestort ist. Wenn die Ver- 
bindung zwischen den beiden Managementebenen, also 
zwischen Agent und Manager, fur eine bestimmte Zeit nicht 
mehr gewahrleistet ist, muB der Agent die wahrend dieses 30 
Intervalls aufgetretenen Alarme zwischenspeichern, urn si- 
cherzustellen, daB nach dem Wiederherstellen der Kommu- 
nikationsmoglichkeit dem Manager zum einen moglichst 
schnell eine Ubersicht der z. Zt. aktiven Alarme z. B. in 
Form einer Liste - zur Verfugung gesteilt wird, und der Ma- 35 
nager zum anderen eine moglichst luckenlose Alarmge- 
schichte ("alarm history") sowohl der aktiven als auch der 
beendeten Alarme ("cleared alarms") aufbauen kann. 

Zu diesem Zweck wird ein Alarmdatenabgleich (alarm 
realignment) zwischen Agent und Manager bei jedem neuen 40 
Verbindungsaufbau nach einem Verbindungsabbruch oder 
nach einer Initialisierung des Agenten oder des Managers 
ausgefuhrt. Alle Alarmdaten aktiver Alarme, zu denen Feh- 
ler im Agent noch nicht behoben sind - erkennbar daran, 
daB sie nicht als "cleared alarms" gekennzeichnet sind - y 45 
sind daher schnellstmoglich und voilstandig der nachsthohe- 
ren Managementebene zur Verfugung zu stellen. 

In der alteren Patentanmeldung P 19752614.4 sind ein 
derartiges Verfahren und Kommunikationssystem zur Be- 
handlung von Alarmen angegeben, die eine Basisfunktiona- 50 
litat fur den Manager zur Anforderung aller Alarme vom 
Agent beschrieben. Dabei sendet der Agent die aktiven 
Alarme als Sequenz standardisierter M-E VENT- REPORTS , 
die in eine vom Manager zu Anfang initiierte M-ACHON- 
Request Anforderung und in eine vom Agent zum Ende in- 55 
itiierte M-ACTION-Response Antwort eingebettet ist. Die- 
ses sind generische CMISE-standardisierte (Common Ma- 
nagement Information Service Element) Prozeduren die ge- 
maB ITU-T X.710 definiert sind. Die ITU-T X.733 definiert 
den Inhalt einer standardisierten Alarmubertragung (alarm 60 
report), die gemaB den M-EVENT-REPORT Services 
durchgefuhrt wird. AUe in Rahmen dieserM- ACTION defi- 
merten M-EVENT-REPORTS sind zu der jeweiligen Anfor- 
derung durch Verwendung von Korrelationsinformationen 
cindcutig korrclicrt. Dies crlaubt dem Manager, dicsc M- 65 
EVENT-REPORTS einer bestimmten Anforderung zuzu- 
ordnen und dariiber hinaus von anderen, ,, regularen ,, M- 
EVENT-REPORTS zu unterscheiden. 



Aufgabe der Erfindung ist es, ein derartiges Verfahren 
und Kommunikationssystem zur Behandlung von Alarmen 
durch ein mehrere Managementebenen aufweisendes Ma- 
nagementnetz anzugeben, durch das ein Alarmdatenab- 
gleich zwischen einem Agent und zumindest einem Mana- 
ger weiter verbessert wird. 

Diese Aufgabe wird gemaB der Erfindung hinsichtlich des 
Verfahrens durch die Merkmale des Paten tanspruchs 1 und 
hinsichtlich des Kommunikationssystems durch die Merk- 
male des Paten tanspruchs 12 gelost. Weiterbildungen der 
Erfindung sind den Unteranspriichen zu entnehmen. 

Die Erfindung geht davon aus, daB fur einen Alarmdaten- 
abgleich zwischen einem Agent einer Managementebene 
und zumindest einem Manager einer nachsthoheren Ma- 
nagementebene die Alarmdaten aktiver Alarme ubenragen 
werden. Dariiber hinaus werden von dem Manager eine oder 
mehrere Anforderungsnachrichten zum Ubermitteln der 
Alarmdaten an den Agent gesendet, sowie Korrelationsin- 
formationen fur eine Zuordnung der jeweiligen Anforde- 
rung zu den vom Agent nachfolgend gesendeten Nachrich- 
ten mit den Alarmdaten empfangen. ErfindungsgernaB wird 
von dem Manager der Alarmdatenabgleich abhangig von 
zumindest einem zum Agent gesendeten Parameter gesteu- 
ert fe 

Durch den Erfindungsgegen stand ist der Alarmdatenab- 
gleich fur den Manager gegeniiber der Basisfunktionalitat 
parametrisierbar, d. h. nicht mehr alle aktiven Alarme mus- 
sen zwangslaufig vom Agent gesendet werden, sondem nur 
die durch den ubermittelten Parameter naher definierten. 
Damit ergibt sich fur den Manager eine Auswahlfunktion 
fur eine Teilmenge aus alien Alarmen. Insbesondere die 
Moglichkeit der steuemden Beeinflussung des Abgleichs 
nut einfachen Mitteln und unter Anwendung standardisier- 
ter Nachrichten erhoht die Flexibility des Managers und re- 
duziert den Nachrichten- und InformationsfluB erheblich. 
Erst durch die parametrisierbare Align ment-Funktionalitat 
gemaB der Erfindung konnen beispielsweise eine Priorisie- 
rung der Alarme und/oder eine aktive Steuerung der Reihen- 
folge der angeforderten Alarme erzielt werden. Besonders 
die Kombination der Basisfunktionalitat - Verwendung der 
Korrelationsinformationen - nut der parametrisierbaren 
Alignment-Funktionalitat fiihrt zu einem besonders effekti- 
ven Verfahren und Kommunikationssystem, das eine opti- 
male Nutzung der Ubertragungsressourcen auf der Schnitt- 
steUe der Agent-Man ager-Beziehung sowie ein schnellst- 
mogliches Bereitstellen nur der vom Manager gewunschten 
Alarmdaten aktiver Alarme fur die nachsthohere Manage- 
mentebene durch den Agent bewirkt. 

GemaB einer Weiterbildung der Erfindung werden von 
dem Manager der oder die Parameter in jeder Anforderungs- 
nachricht zu dem Agent gesendet. Dadurch erfolgt die vom 
Manager gewiinschte Pararnetrisierung des Alarmdatenab- 
gleichs fur jede einzelne Anforderung individuell. 

GemaB einer altemativen Weiterbildung der Erfindung 
werden von dem Manager der oder die Parameter in einer 
den Anforderungsnachrichten vorangestellten Setznachricht 
zu dem Agent gesendet. Dadurch erfolgt die vom Manager 
gewiinschte Pararnetrisierung des Alarmdatenabgleichs vor 
der ersten Anforderungsnachricht gemeinsam fur mehrere 
Anforderungen, fur die die in der Setznachricht enthaltene 
einmalige Einstellung des Managers Gultigkeit hat. 

GemaB weiterer vorteilhafter Weiterbildungen der Erfin- 
dung kann die Pararnetrisierung mit einem oder mehreren 
der folgenden, von dem Manager jeweils eingestellten Para- 
mctcrwcrtcn crfolgcn. Durch den Paramctcrwcrt werden 
vom Agent Alarme angefordert, 



- die von ausgewahlten Agenteinheiten stammen, 
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- fur die eine Dringlichkeit angenommen wird, 

- anhand dessen der Agent eine Priorisierung beim 
Senden der angeforderten Alarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte, vornimmt, 5 

- die innerhalb eines durch einen Anfangszeitpunkt 
und einen Endzeitpunkt definierten Zeitintervalis ent- 
stehen, 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der Aianne nach dem Entstehungszeitpunkt der 10 
Alarme vornimmt. 



Eine Ausgestaltung des Erfindungsgegenstandes sieht 
vor, daB von dem Agent die Alarmdaten der Alarme mit den 
altesten Entstehungszeitpunkten zuerst und die Alarmdaten 15 
der Alarme mit den jiingsten Entstehungszeitpunkten zuletzt 
bereitgestellt und gesendet werden. 

So sieht cine besonders gunstigc Ausgestaltung des Erfin- 
dungsgegenstandes vor, daB von dem Agent die Alarmdaten 
der Alarme mit kritischer Dringlichkeit bei der die Funktio- 20 
nalitat als nicht mehr gegeben angenommen wird, zuerst 
und die Alarmdaten der Alarme mit unkritischer Dringlich- 
keit, bei der die Funktionalitat als nicht mehr gegeben ange- 
nommen wird, zuletzt bereitgestellt und gesendet werden. 

Mit der obigen Vorgehensweise kann der Manager die im 25 
Hinblick auf die Funktionalitat besonders kritischen und da- 
mit fur ihn wichtigen Alarme gezielt abrufen, und dabei die 
Schnittstelle zum Agent durch den nur auf bestimmte 
Alarme eingeschrankten InformationsfluB gegenuber dem 
herkommlichen Verfahren der automatischen Meldung aller 30 
Alarme wesentlich entlasten. 

Nachstehend wird die Erfindung anhand von Ausfiih- 
rungsbeispielen unter Bezugnahnie auf die Figuren naher er- 
lautert. Es zeigen 

Fig. 1 das Blockschaltbild eines Managementnetzes fur 35 
ein Mobil- Kommunikationssystem mit Agent-Manager-Be- 
ziehung zwischen einem Betriebs- und Wartungszentrum 
und einem oder mehreren Netzmanagementzentren, 

Fig. 2 das Blockschaltbild des Managementnetzes gemaB 
Fig. 1 mit Agent-Manager-Beziehung zwischen einem Ba- 40 
sisstationssystem und einem Betriebs- und Wartungszen- 
trum zur Durchfuhrung von zumindest zwei Anwendungen 
fiir das Basisstationssystem, 

Fig. 3 das Blockschaltbild von Agent und Manager zur 
Behandlung der Alarme fur parallel oder seriell ablaufende 45 
Alarmdatenabgleiche, 

Fig. 4 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur individuellen parameterabhangigen Steue- 
rung des Alarmdatenabgleichs in jeder Anforderungsnach- 
richt, ~ 50 

Fig. 5 den NachrichtenfluB nach Fig. 4 am Beispiel der 
Verwendung von zwei verschiedenen Parameterwerten. 

Fig. 6 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur parameterabhangigen Steuerung des Alarm- 
datenabgleichs durch eine einmalige Einsteliung fur men- 55 
rere Anforderungsnachrichten. 

Fig. 7 den NachrichtenfluB nach Fig. 6 am Beispiel der 
Verwendung von zwei verschiedenen Parameterwerten, und 
Fig. 8 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur Abfrage der fur den Alarmdatenabgleich be- 60 
nutzten Parameterwerte nach Fig. 7. 

Das Ausfuhrungsbeispiel beschreibt die Erfindung an- 
hand eines TMN-Konzepts fiir das Management eines Mo- 
bil- Kommunikationssys terns, das beispielsweise Netzein- 
richtungen eines Mobilfunknctzcs nach dem GSM-Standard 65 
aufweist. Die Erfindung ist aber nicht auf Mobilfunknetze 
beschrankt, sondern laBt sich auf Telekommunikationsnetze 
jeder Art, die ein TMN-Managementnetz nutzen, anwenden. 



Ein Mobil-Kommunikationssystem ist ein hierarchisch 
gegliedertes System verschiedener Netzeinrichtungen, bei 
dem die unterste Hierarchiestufe von den Mobilstationen 
gebildet wird. Diese Mobilstationen kommunizieren uber 
eine Funkschnittsteile mit die nachste Hierarchieebene bil- 
denden Funkstationen, die als Basisstationen bezeichnet 
werden. Die beispielsweise Mobilstationen in einem Funk- 
bereich einer Funkzelle versorgenden Basisstationen sind 
vorzugsweise zur Abdeckung eines groBeren Funkgebiets 
zusammengefaBt und mit ubergeordneten Netzeinrichtun- 
gen, den Basisstationssteuerungen verbunden. Die Basissta- 
tionen und Basisstationssteuerungen gehoren zu einem Ba- 
sisstationssystem (Base Station Subsystem) des Mobil- 
Kommunikationssystems. Die Basisstationssteuerungen 
kommunizieren iiber definierte Schnittstellen mit einer oder 
mehreren Vermittlungseinrichtungen, den Mobilvermitt- 
lungsstellen, uber die u. a. auch der Ubergang zu anderen 
Kommunikationsnctzcn crfolgt Die Mobilvcrmittlungsstcl- 
len bilden gemeinsam mit einer Mehrzahl von Datenbanken 
das Vermittlungssystem (Switching Subsystem) des Mobil- 
Kommunikationssystems. 

Neben den obigen Netzeinrichtungen existieren ein oder 
mehrere Betriebs- und Wartungszentren (Operation and 
Maintenance Centers), die u. a. zum Konfigurieren und 
Uber wachen der NetzeinrichUingen dient. Uberwachungs- 
maBnahmen und KonfigurierungsmaBnahmen werden 
hierzu meist vom Betriebs- und Wartungszentrum aus fern- 
gesteuert, die iiblicherweise im Bereich der Mobilvermitt- 
lungsstellen angeordnet sind. Ein Betriebs- und Wartungs- 
zentrum kommuniziert dabei jeweils mit einem Basisstati- 
onssystem oder Vermittlungssystem iiber eine definierte 
Schnittstelle. Eine weitere Aufgabe des Betriebs- und War- 
tungssy stems ist die Durchfuhrung des Konfigurationsma- 
nagements (Configuration Management), das neben dem 
Fehlermanagernent einen von funf Managementfunktions- 
bereichen darstellt, die die TMN-Prinzipien idendfizieren. 
Das Konfigurationsmanagement definiert eine Reihe von 
Diensten, die eine Anderung der Strukturund damit des Ver- 
haltens eines Telekommunikationsnetzes durch den Bedie- 
ner ermoglichen. Diese Dienste beziehen sich immer auf In- 
stanzen von gemanagten Objekten, die insgesamt die netz- 
spezifische ManagemenUnformationsbasis bilden. 

Ein gemanagtes Objekt im Sinne des Konfigurationsma- 
nagements ist eine logische Abstraktion einer Ressource im 
Mobil-Kommunikationssystem. Hierbei wird unterschieden 
zwischen hardwarebezogenen gemanagten Objekten, die 
eine herstellerspezifische Realisierung einer Funktion be- 
schreiben, und funktionsbezogenen gemanagten Objekten, 
bei denen es sich jeweils um die Abstraktion einer herstel- 
lerunabhangigen Funktionalitat handelt. 

Fiir das Management des Mobil-Kommunikationssy- 
stems definieren die TMN-Prinzipien mehrere Ebenen ("Le- 
vels"), von denen im vorliegenden Beispiel drei Ebenen un- 
ter Bezugnahme auf die Fig. 1 und 2 nachfolgend eriautert 
werden. 

Die Fig. 1 und 2 zeigen jeweils drei Ebenen A, B und C 
des Managementnetzes, von denen die Managementebene C 
die Netzeinrichtungsebene ("Network Element Level") mit 
mehreren Basisstationssystemen BSS11,BSS12 . . . BSS1N 
sowie BSS21, BSS22 . . . BSS2M enthalt. Die Manage- 
mentebene B kennzeichnet die Netzeinrichtungsmanage- 
mentebene ("Network Element Management Level"), in der 
Betriebs- und Wartungszentren OMC1 und OMC2 jeweils 
die herstellerspezifische Managementfunktionalitat fur ein- 
zclnc Subsystcmc, wic im vorliegenden Beispiel das Be- 
triebs- und Wartungszentrum OMC1 fiir die Basisstations- 
systeme BSS11, BSS12 . . . BSS1N und das Betriebs- und 
Wartungszentrum OMC2 fur die Basisstationssysteme 
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BSS21, BSS22 . . . BSS2M, bereitstellen. Die Management- 
ebene A kennzeichnet die Netzmanagementebene ("Net- 
work Management Level"), in der Netzmanagementzentien 
NMC1 und NMC2 jeweils eine integrierte, vom Hersteller 
unabhangige Management-Funktionalitat realisieren. Dabei 5 
konnen mehrere Netzmanagementzentren einen Zugriff zu 
derselben Netzeinrichtung der nachstniedrigeren Manage- 
mentebene B haben, im vorliegenden Beispiel die Netzma- 
nagementzentren NMC1 und NMC2 der nachsthoheren Ma- 
nagementebene C zum Betriebs- und Wartungszentrum 10 
OMC1 der nachstniedrigeren Managementebene B. Zwi- 
schen den Netzeinrichtungen unterschiedlicher Manage- 
mentebenen sind definierte Schnittstellen zur Informauons- 
ubertragung vorgesehen. 

Der Unterschied in den Darstellungen gemaB den Fig. 1 15 
und 2 liegt darin, daB eine Agent-Manager-Beziehung zur 
Behandlung von Alarmen fur einen oder mehrere Alarmda- 
tcnabglcichc in Fig. 1 zwischcn dcm Betriebs- und War- 
tungszentrum OMC1 (Agent) und einem Netzmanagement- 
zentrum NMC1 (Manager) oder rnehreren - physikalisch 20 
getrennten - Netzmanagementzentren NMC1, NMC2 (Ma- 
nager) sowie in Fig. 2 zwischen dem Basisstationssystem 
BSSl 1 (Agent) und zwei verschiedenen Anwendungen OF1 
und OF2 (Manager) in dem Betriebs- und Wartungszentrum 
OMC1 oder zwischen dem BeLriebs- und Wartungszentrum 25 
OMC1 (Agent) und zwei verschiedenen Anwendungen NF1 
und NF2 (Manager) in dem Netzmanagementzentrum 
NMC1 besteht. Um in den Netzmanagementzentren NMC1. 
NMC2 jederzeit einen Uberblick uber die Fehlersituation si- 
cherzustellen, werden vom Betriebs- und Wartungszentrum 30 
OMC1 die - auf Grund von beispielsweise innerhalb der be- 
treuten Basisstationssysteme BSS11 . . . BSS1N auftreten- 
den Fehlern - gespeicherten Alarmdaten aktiver Alarme be- 
reitgestellt und parallel zu beiden Managern auf Anforde- 
rung gesendet. Dies erfolgt vorzugsweise nach einem Ver- 35 
bindungsabbruch oder nach einer Initialisierung des Agen- 
ten oder des Managers. Ebenso konnen mehrere Anforde- 
rungen auch hintereinander von einem einzelnen Manager, 
z. B. dem Netzmanagementzentrum NMC1 an den Agent! 
z. B. dem Betriebs- und Wartungszentrum OMC1, gerichtet 40 
werden. Fig. 1 zeigt die Struktur fur gemaB der Erfindung 
mehrfach ausgesendete Anforderungen zum Alarmdatenab- 
gleich, die im vorliegenden Beispiel parallel zwischen der 
Managementebene B, in der sich der Agent in Form des Be- 
triebs- und Wartungszentrums OMC1 befindet, und der 45 
nachsthoheren Managementebene A, in der die Manager 
von zumindest zwei Netzmanagementzentren NMC1, 
NMC2 gebildet werden, ablaufen. 

Um auch in der Managementebene B, z. B. in dem Be- 
triebs- und Wartungszentrum OMC1 jederzeit einen Uber- 50 
blick uber die Fehlersituation sicherzustellen, werden vom 
Basisstationssystem BSS11 die - auf Grund von beispiels- 
weise innerhalb der betreuten Basisstationen und Basisstati- 
onssteuerungen auftretenden Fehlern - gespeicherten 
Alarmdaten aktiver Alarme bereitgestelit und parallel zu 55 
mindestens zwei Managern des Betriebs- und Wartungszen- 
trums OMC1 in Form der unterschiedlichen Anwendungen 
OF1 und OF2, die beide von ein- und derselben physikali- 
schen Einrichtung OMC1 ausgefuhrt werden, gesendet. 
Dies erfolgt ebenfalls vorzugsweise nach einem Verbin- 60 
dungsabbruch oder nach einer Initialisierung des Agenten 
oder des Managers. Eine serielle Ubertragung von mehrfach 
durch einen einzelnen Manager, z. B. dem Betriebs- und 
Wartungszentrum OMC1, initiierten Anforderungen an den 
Agent, z. B. dcm Basisstationssystem BSS11, ist ebenfalls 65 
moglich. Alternativ oder zusatzlich kann eine Agent-Mana- 
ger Beziehung auch zwischen dem Betriebs- und Wartungs- 
zentrum OMC1 (ein Agent) und dem Netzmanagementzen- 



trum NMC1 (ein Manager) zum serieUen Austausch von 
Anforderungen und Alarmdaten oder zum parallelen Aus- 
tausch von Anforderungen und Alarmdaten fur mindestens 
zwei unterschiedliche Anwendungen NF1 und NF2 (zwei 
Manager) im Netzmanagementzentrum NMC1 existieren. 
Fig. 2 zeigt die Struktur fur gemaB der Erfindung parallel 
ablaufende Alarmdaten abgleiche zwischen der Manage- 
mentebene B, in der sich die Manager als Anwendungen 
OF1 und OF2 befinden, und der nachstniedrigeren Manage- 
mentebene C, in der sich der Agent befindet. 

Sobald eine in der Managementebene C ausgefallene in- 
terne vSchnittstelle wieder betriebsbereit ist, wird auf Anfor- 
derung des Managers/der Manager der Alarmdatenabgleich, 
auch als Realignment-Prozedur oder Realignment- Verfah- 
ren bezeichnet, gestartet, wobei gemaB der Erfindung vom 
Manager der Alarmdatenabgleich parameterabhangig ge- 
steuert wird. Dabei beginnt der Alarmdatenabgleich im vor- 
liegenden Beispiel zucrst zwischen dcm Basisstationssy- 
stem, z. B. BSS1 1, und den Anwendungen OF1, OF2 im Be- 
triebs- und Wartungszentrum OMC1 parallel und setzt sich 
anschlieGend zwischen dem Betriebs- und Wartungszentrum 
OMC1 und den ubergeordneten Netzmanagementzentren 
NMC1, NMC2 parallel fort. Am Ende dieser Prozeduren ist 
die Fehlersituation sowohl im OMC als auch in den NMC 
wieder aktualisiert. Das Realignment- Verfahren kann selbst- 
verstandlich auf die Aktualisierung der Alarmdaten zwi- 
schen Agent und Managern in zwei unmittelbar angrenzen- 
den Managementebenen, z.B. Ebene B und Ebene A. be- 
schrankt sein. 

Fig. 3 zeigt in schematischer Darstellung den Aufbau von 
Agent AG und Manager MA 1 , MA2 mit den zur Durchfuh- 
rung simultan - bei zwei oder rnehreren Managern - oder 
seriell - bei nur einem Manager - ablaufender Realignment- 
Prozeduren erforderlichen Einrichtungen. Jeder Manager 
MAI, MA2 und Agent AG verfugt uber eine Steuereinrich- 
tung M-CTR bzw. A-CTR, die die Nachrichten fur den 
Alarmdatenabgleich generieren und auswerten konnen. 
Ebenso weisen sie - nicht naher dargestellte - Sende/Emp- 
fangseinrichtungen fur das Versenden und Empfangen der 
Nachrichten sowie Speichereinrichtungen fur das Speichem 
der Alarmdaten und andererNutz- und Signalisierungsinfor- 
mationen auf. 

Dabei fugen die Steuereinrichtungen M-CTR der Mana- 
ger MAI, MA2 in die jeweilige Anforderungsnachricht zur 
Ubermittlung der Alarmdaten durch den Agent eine zur Zu- 
ordnung der Anforderung zu nachfolgend gesendeten Nach- 
richten benutzte Korrelationsinformadon ein, die eindeutig 
ist, und veranlaBt die Ubertragung zum Agent. Daruber hin- 
aus fugen die Einrichtungen M-CTR der Manager MAI, 
MA2 zur Steuerung des Aiarmdatenabgleichs einen oder 
mehrere Parameter par in jede Anforderungsnachricht indi- 
vidual oder in eine den Anforderungsnachrichten vorange- 
stellte Setznachricht ein, um bestimmte, durch verschiedene 
Parameterwerte gekennzeichnete Alarme gezielt anzufor- 
dern. Die jeweilige Anforderungsnachricht bzw. die geson- 
derte Setznachricht wird mit den Parametern par zum Agent 
AG gesendet. Erst durch die parametrisierbare Alignment- 
Funktionalitat gemaB der Erfindung konnen beispielsweise 
eine Priorisierung der Alarme und/oder eine aktive Steue- 
rung der Reihenfolge der angeforderten Alarme erzielt wer- 
den. 

Die Steuereinrichtung A-CTR des Agent AG empfangt 
die entsprechende Nachricht mit den Parametern par, wertet 
sie aus, und startet das ReaUgnment zu den Managern MAI, 
MA2 durch Riickscndcn der von den Managern spczifisch 
angeforderten Alarme. Dabei wird die von den Managern 
MAI, MA2 in die Anforderungsnachricht eingetragene ein- 
deutige Korrelationsinformation zur Korrelation der Anfor- 
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clerungen benutzt, und jeweils eine Nachricht mit einer wei- 
teren Korrelationsinformation zur Zuordnung der nachfol- 
gend vom Agent gesendeten Nachrichten (alarm notificati- 
ons) zu dem jeweils gestartelen Realignment in die nachst- 
hohere Managementebene gesendet. Auch die weitere Kor- 
relationsinformation ist eindeutig. Durch die Verwendung 
der Korrelationsinfonnationen ist eine eindeutige Zuord- 
nung simultan oder seriell durchgefuhrter Realignments zu 
inehreren Managern oder einern einzelnen Manager mog- 
lich. 

Besonders die Kombination der Basisfunktionalitat- Ver- 
wendung der Korrelationsinformationen - mit der parame- 
trisierbaren Alignment-Funktionalitat fuhrt zu einem beson- 
ders effektiven Verfahren und Kommunikationssystem, das 
eine optimale Nutzung der Ubertragungsressourcen auf der 
Schnittstelle der Agent-Manager-Beziehung sowie ein 
schnellstmogliches Bereitstellen nur der vom Manager ge- 
wiinschtcn Alarmdatcn aktivcr Alarmc fur die nachsthohcrc 
Managementebene durch den Agent bewirkt. Ressourcen- 
ausnutzung, Zeitdauer und Flexibility werden folglich in 
dem erfindungsgemaB ausgestalteten Kommunikationssy- 
stem gegenuber der Basisfunktionalitat weiter optimiert. 

Wahlweise konnen im Agent AG mehrere, jeweils den 
Managern MAI, MA2 zuordenbare und von ihnen steuer- 
bare Filterfunktionen EFD1, EFD2 (Event Forwarding Di- 
scriminators) mit Filterkriterien fur die vom Agent AG er- 
zeugten Nachrichten mit benutzt werden, sodaB die Nach- 
richten mit den Alarmdaten nur bei Erfullen der Filterkrite- 
rien zu den Managern MAI, MA2 geroutet werden. Die 
Steuereinrichtung M-CTR des Managers ist in der Lage, 
derartige Filterfunktionen im Agent AG einzurichten, zu 16- 
schen und die Filterkriterien festzulegen, um je nach seinen 
individuellen Anforderungen den Nachrichten ft uB steuern 
zu konnen. Daher kann der Fall auftreten, daB die Filter- 
funktions-Einstellung von Manager zu Manager unter- 
schiedlich ist, sodaB durch die simultan ablaufenden Reai- 
ignment-Prozeduren inhaltlich verschiedene Aiarme mit zu- 
gehorigen Alarmdaten behandelt werden. 

Fig. 4 zeigt den NachrichtenfluB zwischen einem Agent 
AG - im dargestellten Beispiel gemaB der Fig. 1 dem Be- 
triebs- und Wartungszentrum OMC1 oder im dargestellten 
Beispiel der Fig. 2 dem Basisstationssystem BSS11 - und 
dem Manager MAI, MA2 - im Beispiel gemaB der Fig. 1 
den unterschiedlichen Netzmanagementzentren NMC1, 
NMC2 oder im Beispiel der Fig. 2 den verschiedenen App- 
likationenOFl,OF2. 

Der NachrichtenfluB erfolgt vorzugsweise unter Verwen- 
dung standardisierter M-EVENT-REPORT Nachrichten, die 
in eine zu Anfang initiierte M-ACTION-Request Anforde- 
rung und in eine zum Ende initiierte M-ACTION-Response 
Antwort eingebettet sind. Dieses sind generische CMISE- 
standardisierte (Common Management Information Service 
Element) Prozeduren, die gemaB ITU-T X.710 definiert 
sind. Die ITU-T X.733 definiert den Inhalt einer standardi- 
sierten Alarmubertragung (alarm report), die gemaB den M- 
E VENT-REPORT Services durchgefuhrt wird. Die Korrela- 
tionsinformationen werden in die Nachrichten bzw. in be- 
stimmte Nachrichtenfelder eingetragen. Des weiteren verse- 
hen die Manager MAI, MA2 die Parameter zur Steuerung 
des Alarmdatenabgleichs mit bestimmten Parameterwerten 
und tragen sie einzeln oder mehrfach in die jeweilige Anfor- 
derungsnachricht ein. Das Beispiel in Fig. 4 zeigt den Nach- 
richtenfluB nur anhand einzelner Nachrichten, wobei diese 
parallel zwischen dem Agent AG und den Managern MAI, 
MA2 oder scricll zwischen dem Agent AG und dem einzel- 
nen Manager MAI ubertragen werden konnen. 

Sobald nach einer Unterbrechung der Verbindung die 
Kommunikation zwischen dem Manager MAI, MA2 und 



dem Agent AG wiederhergesteilt ist, sendel jeder Manager 
MAI, MA2 die M-ACTTON-Request Anforderung mit ei- 
ner Anforderungsnachricht repAA (report Active Alarms) 
zum Ubermitteln der Alarmdaten. Vorzugsweise wird eine 

5 vom Manager MAI, MA2 definiert e Korrelationsinforma- 
tion alaAH (alarm Alignment Handle) - beispielsweise im 
definierten Nachrichtenfeld "acuonlnformation" - mitge- 
sendet, die eine direkte Zuordnung der aktuellen M-AC- 
TION-Request Anforderung zu alien nachfolgenden Agent- 

10 Nachrichten kennzeichnet. Damit ist bei mehreren Mana- 
gern die aktuelle Anforderung auch dem jeweiligen Mana- 
ger zuordenbar, sodaB die parallelen Realignments der Ma- 
nager voneinander unabhangig initiiert, durchgefuhrt und 
beendet werden konnen. 

15 Die Anforderungsnachricht repAA enthalt auch die vom 
Manager eingetragenen Parameterwerte fiir den nachfolgen- 
den Funktionsablauf. Damit wird eine einmalige individu- 
cllc Funktionsausfuhrung (Action) zur paramctcrabhangi- 
gen Ubermittlung von Alarnien vom Agent AG angefordert. 

20 Die Parametrisierung kann vorzugsweise mit einem oder 
mehreren eingestellten Parameterwerten relEN (related En- 
tities), relPS (related perceived Severity), priSV (prio seve- 
rity), relTI (related Time Interval), priDT (prio Detection 
Time) erfolgen. Durch den spezifischen Parameterwert wer- 

25 den vom Agent Aiarme angefordert, 

- die von ausgewahlten Agenteinheiten stammen (re- 
1EN), 

- fur die eine Dringlichkeit angenommen wird (relPS), 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der angeforderten Aiarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte (priSV), vornimmt, 

die innerhalb eines durch einen Anfangszeitpunkt 
und einen Endzeitpunkt definierten Zeitintervalls ent- 
stehen (relTI), 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der Aiarme nach dem Entstehungszeitpunkt der 
Aiarme vornimmt (priDT). 



30 



3S 



40 

Die Parameterwerte relEN . . . sind in einem gemaB dem 
Standard vorgegebenen Nachrichtenfeld der M-ACTION- 
Request Anforderung enthalten, um bereits vorhandene und 
definierte Felder mitbenutzen zu konnen. Eine gunstige Va- 

45 riante unter Einbeziehung der Zeit besteht darin, daB von 
dem Agent die Alarmdaten der Aiarme mit den altesten Ent- 
stehungszeitpunkten zuerst und die Alarmdaten der Aiarme 
mit den jiingsten Entstehungszeitpunkten zuletzt bereitge- 
stellt und gesendet werden. Eine besonders geeignete Va- 

50 riante der Kombination der Parameterwerte bezuglich Zeit 
und Dringlichkeit besteht darin, daB von dem Agent die 
Alarmdaten der Aiarme mit kritischer Dringlichkeit, bei der 
die Funktionalitat. als nicht mehr gegeben angenommen 
wird, zuerst und die Alarmdaten der Aiarme mit unkritischer 

55 Dringlichkeit, bei der die Funktionalitat als noch gegeben 
angenommen wird, zuletzt bereitgestellt und gesendet wer- 
den. 

Im AnschluB an die Auswertung der Parameter in der ein- 
getroffenen M-A(mON-Request Anforderung und der Be- 

60 reitstellung nur der Alarmdaten, die zu den vom Manager in 
der parametrisierten Anforderung definierten Alarmen ge- 
horen, startet der Agent AG den Alarmdatenabgleich durch 
Erzeugen einer Nachricht staAA (start Alarm Alignment) 
und Einfugen einer weiteren Korrelationsinformation aliNI 

65 (alignment Notification Id) in dicsc Nachricht. Die vom 
Agent AG eingetragene Korrelationsinformation aliNI er- 
moglicht eine direkte Korrelation nachfolgender Aiarme zu 
dem jeweils gestarteten Alarmdatenabgleich. Dabei ist die 
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Korrelationsinformation alaAH ebenfaUs in einem be- 
stimmten Nachrichtenfeld enthalten. Die Korrelationsinfor- 
mation aliNl ist beispielsweise in dem standardisierten 
Nachrichtenfeld "notification Identifier" der Nachricht 
staAA eingetragen. Beide Informationen alaAH. aliNI wer- 
den gemeinsam in der Nachricht staAA vom Agent AG zu 
den Managem MAI, MA2 ausgesendet. Dadurch konnen 
"alignmentbezogene" M-EVENT-REPORT Nachrichten 
verschiedener M-ACTION-Requests voneinander unter- 
schieden werden, aber auch von regularen M-EVENT-RE- 
PORT Nachrichten, die mit dem Datenabgleich nichts zu tun 
haben. Eine Alignment-Prozedur stoppt namlich nicht zwin- 
gend andere M-EVENT-REPORT Nachrichten, die wah- 
rend der Alignment-Prozedur spontan auftreten und an den 
oder die Manager gesendet werden. 

Uber die in der Anforderungsnachricht rep A A des M- 
ACTION-Requests milgesendete Korrelationsinformation 
alaAH lasscn sich dirckt die folgcndcn Nachrichten staAA 
sowie repAA korrelieren, da sie ebenfaUs die Korrelations- 
information alaAH enthalten. Die Nachrichten alNO sind 
uber die Korrelationsinformation aliNI mit der Nachricht 
staAA direkt korreliert. Der Manager kann die Anforde- 
rungsnachricht repAA mit den nachfolgenden Nachrichten 
alNO indirekt uber die beiden in der Nachricht staAA ent- 
haltenen Korrelationsinfonnationen alaAH und aliNI korre- 
lieren. 

Im AnschluB an den Start des Alarmdatenabgleichs er- 
folgt die sukzessive Ubertragung der Alanne mit den zuge- 
horigen Alarmdaten in aufeinanderfolgenden Nachrichten 
alNO (alarm notification) unter Verwendung des M- 
EVENT-REPORT Service. Dabei weisen die einzelnen 
Nachrichten alNO jeweils die Korrelationsinformation 
aliNI - beispielsweise in dem definierten Nachrichtenfeld 
"correlated Notifications" auf. Nach der letzten M- 
EVENT-REPORT Nachricht des Alarmdatenabgleichs ge- 
neriert der Agent AG die M-ACTION-Response Antwort 
zur Nachricht repAA (report Active Alarms), die die Korre- 
lationsinformation alaAH zur eindeutigen Kennung der je- 
weiligen Anforderung des Managers MAI, MA2 enthalt. 
Durch Auswertung dieser Korrelationsinformation kann je- 
der Manager MA 1 , MA2, das Ende seiner initiierten M-AC- 
TTON-Request Anforderung auf einfache Art und Weise er- 
kennen und die eintreffenden Alarmdaten den Anforderun- 
gen zuordnen. Fiir den Fall, daB zum Zeitpunkt der M-AC- 
TION-Request Anforderung keine aktiven Alarme gespei- 
chert sind, initiiert der Agent die M-ACTION-Response 
Antwort unmittelbar nach dem Senden der Nachricht 
staAA. Die Korrelationsinformationen alaAH, aliNI fur die 
eindeutige Zuordnung mehrerer Anforderungen - moglicher 
simultaner Realignments zu mehreren Managern oder seri- 
eller Realignments zu einem einzelnen Manager - werden 
dennoch von den in der Agent-Manager-Beziehung invol- 
vierten Einrichtungen generiert und in den Nachrichten re- 
pAA, staAA gesendet. Auch wenn das zu Fig. 4 beschrie- 
bene Bei spiel sich auf parallel Realignments zu mehreren 
Managern bezieht, kann der NachrichtenfluB selbstverstand- 
lich auf mehrere, von einem einzigen Manager nacheinander 
ausgeloste Anforderungen angewendet werden, mit dem 
VorteiL daB durch die eindeutige Zuordnung anhand der 
Korrelationsinformationen fur den einzelnen Manager die 
Moglichkeit besteht, die eintreffenden Antworten des Agen- 
ten mit den Alarmdaten auch bei Nichteinhalten derReihen- 
folge eindeutig den Anforderungen zuordnen zu konnen - 
beispielsweise unterschiedlichen Anwendungen im Mana- 
ger. Nacheinander gcscndctc Anforderungen konnen sich 
gegebenenfalls gegenseitig uberholen, beispielsweise dann, 
wenn zwischen Agent und Manager ein Paketnetz durchlau- 
fen wird. 



Fig. 5 zeigt den NachrichtenfluB gemaB Fig. 4 bei Ver- 
wendung von zwei verschiedenen Parameterwerten, die im 
vorliegenden Beispiel von den Parameterwerten priSV und 
relTI gebildet sind. Der Parameterwert. priSV nimmt den 
5 Wert TRUE an, was dem Agent signalisiert, daB er bei der 
Sendereihenfolge der Alarme nach unterschiedlichen Dring- 
lichkeitswerten priorisieren soli. Fur den Fall, daB der Para- 
meterwert priSV einen anderen Wert (z. B. FALSE) an- 
nimmt, verzichtet der Agent auf die Priorisierung nach 
to Dringlichkeitswerten. Wird das optional vorhandene Feld 
vom Manager zur Steuerung der angeforderten Alarme erst 
gar nicht benutzU werden alle aktive Alarme, die eine ange- 
nommen Dringlichkeit aufweisen, iibertragen (default-Mo- 
dus). Der zweite Parameterwert relTI enthalt eine Sequenz 
15 von zwei Werten inst (Interval Start) und inen (Interval 
End), die einen Anfangszeitpunkt und einen Endzeitpunkt 
zur Festlegung eines Zeitintervalls markieren. Dies bedeu- 
tct, daB nur die Alarme vom Agent angefordert werden, die 
innerhalb des durch inst, inen gekennzeichneten Zeitinter- 
20 vails entstehen. Wird das optional vorhandene Feld vom 
Manager zur Steuerung der angeforderten Alarme erst gar 
nicht benutzt, werden alle aktive Alarme ohne Beriicksichti- 
gung des Entstehungszeitpunkts ubertragen (default-Mo- 
dus). Im vorliegenden Beispiel werden gezielt nur die 
25 Alarme - priorisiert nach deren Dringlichkeit (siehe obige 
Ausfiihrungen) -, die zwischen "inst = 12.01.98 10:15:00" 
und "inen = 12.01.98 11:15:00" auftreten, vom Agent zur 
Verfugung gestellt und zum Manager gesendet. 

GemaB dem Beispiel in Fig. 5 werden in den auf die 
30 Nachricht staAA folgenden Nachrichten alNO die Alarmda- 
ten der ausgewahlten Alarme unter Verwendung des M- 
EVENT-REPORT Service gesendet. Die einzelnen Nach- 
richten alNO weisen neben der Korrelationsinformation 
aliNI einen Wert fur die Dringlichkeit SV (perceived Seve- 
35 rity) des Alarms und einen Entstehungszeitpunkt evT (event 
lime) des Alarms auf. Die unterschiedlichen Dringlich- 
keitswerte reichen von "kritisch" cri (critical) uber "wichtig" 
maj (major), "weniger wichtig" min (minor) bis zu "unkri- 
tisch" war (warning). Als kritisch wird ein Alarm aufgefasst, 
40 bei der die Funktionalitat als nicht mehr gegeben angenom- 
men wird, wahrend bei einem unkridschen Alarm die Funk- 
tionalitat als noch gegeben angenommen wird. Empfangt 
der Manager den Dringlichkeitswert war, fasst er diesen 
Alarm als Warnung bezughch einer moglichen Beeintrachti- 
45 gung der Funktionen des Agent auf. 

Durch die eingestellten Parameter beziiglich der Dring- 
lichkeit und des vom Agent zu uberprufenden Zeitintervalls 
weisen die beiden zuerst ges endeten Nachrichten alNO die 
Werte S V=cri fur das Vorliegen kritischer Dringlichkeit mit 
50 zugehorigen Werten evT = 10:50:30 und evT = 10:20:20 fur 
die Zeitpunkte ihres Auftretens. Die beiden nachstfoigenden 
Nachrichten alNO enthalten die Werte SV=maj, evT = 
10:25:50 zur Kennzeichnung eines Alarms mit einer wichti- 
gen Dringlichkeit und die Werte SV=min, evT = 10:22:10 
55 zur Kennzeichnung eines Alarms mit einer weniger wichti- 
gen Dringlichkeit. Die im Beispiel zuletzt gesendete Nach- 
richt alNO umfasst die Werte SV=war, evT = 10:17:30, ent- 
sprechend der Anzeige einer Warnung an den Manager. Die 
Nachrichtensequenz ist ftir das individuelle Anfordern be- 
60 sdmmter Alarme durch Einstellung der Parameter in jeder 
Anforderungsnachricht repAA geeignet. 

Im Gegensatz zu der Einstellung pro M- ACTION Re- 
quest Anforderung zeigt Fig. 6 den NachrichtenfluB zwi- 
schen dem Manager und dem Agent zur pararneterabhangi- 
65 gen Steuerung des Alarmdatenabgleichs durch cine cinma- 
lige Einstellung der Parameter, die fur mehrere anschlie- 
Bende Anforderungsnachrichten repAA Gultigkeit hat. Da- 
mit wird in vorteilhafter Weise eine Parametrisierung fur 
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den Alarmdatenabgleich erzielt, ohne daB es jedes Mai einer 
Neueinstellung der Parameter bedarf. Zu diesem Zweck ist 
den Anforderungsnachrichten repAA gemaB M- ACTION 
Request, von denen beispielhaft. nur eine dargestellt ist, eine 
Nachricht M-SET vorangestellt, mit der der oder die vom 5 
Manager eingefugten Parameter relEN, relPS, priSV, relTI, 
priDT im Agent als Auswahlkriterien fiir die zu ubertragen- 
den Alarme gesetzt werden. 

Fig. 7 zeigt den zur Vorgehensweise von Fig. 6 gehorigen 
NachrichtenfluB bei Einstellung der zu Fig. 5 bereits be- 10 
schriebenen beiden Parameter priSV, relTT. Im Unterschied 
zu Fig. 5 werden das durch den Anfangszeitpunkt inst und 
den Endezeitpunkt inen festgelegte Zeitintervall als Parame- 
terwert relTI -nur in diesem Zeitfenster sollen vom Agent 
Alarme registriert und nach Dringlichkeit priorisiert werden 15 
- und die Dringlichkeit als Parameterwert priS V vom Mana- 
ger in die Setznachricht M-SET eingefugt und vorab zum 
Agent gesendct. Die Einstcllungcn bchaltcn fiir allc darauf- 
folgenden Anforderungsnachrichten ihre Giilligkeit, bis eine 
neue Setznachricht M-SET die bisherigen Parameter iiber- 20 
schreibt oder fiir ungiiltig erklart. Die Nachrichten alNO 
enthalten dieselben Parameterwerte, die in Fig. 5 beispiel- 
haft angegeben und laut den zugehorigen Ausfiihrungen be- 
schrieben sind. 

Fig. 8 zeigt den NachrichtenfluB zwischen dein Manager 25 
und dem Agent zur Abfrage der fur den Alarmdatenabgleich 
benutzten und im Agent eingestellten Parameterwerte nach 
Fig. 7, die mit der vorab gesendeten Setznachricht an den 
Agent ubermittelt wurden. Zu diesem Zweck generiert der 
Manager eine M-GET Request Anforderung mit den abzu- 30 
fragenden Parameterwerten - im Bei spiel den Parameter- 
werten priSV, relTI - und sendet sie zum Agent. Als Ant- 
wort erhalt der anfragende Manager eine Nachricht M-GET 
Response mit den im Agent aktuell giiltigen Einstellungen 
fiir die vorgegebenen Parameterwerte. Im vorliegenden Bei- 35 
spiel besteht die Ruckmeldung des Agent in der Nachricht 
M-GET response aus den Werten priSV=TRUE und relTI 
(inst = 12.01.98 10:15:00, inen = 12.01.98 11:15:00). Auf 
diese Weise kann der Manager uberprufen, welche aktuelle 
Einstellung vorliegt, urn ggf. Anderungen beim spateren 40 
Anfordern bestimmter Alarme durch aufeinandeifolgendes 
Erzeugen und Senden von Anforderungsnachrichten zu tati- 
gen. 

Patentanspriiche 45 

1. Verfahren zur Behandlung von Alarmen in einem 
Kommunikationssystem durch ein mehrere Manage- 
mentebenen (A, B, C) aufweisendes Managementnetz, 
wobei fur einen Alarmdatenabgleich zwischen einem 50 
Agent (AG) einer Managementebene (B, C) und zu- 
mindest einem Manager (MAI, MA2) einer nachstho- 
heren Managementebene (A, B) die Alarmdaten akti- 
ver Alarme iibertragen werden, bei dem 

- von dem Manager (MAI, MA2) jeweils eine 55 
oder mehrere Anforderungsnachrichten (repAA) 
zum Ubermitteln der Alarmdaten an den Agent 
(AG) gesendet werden, 

- von dem Manager (MAI, MA2) Korrelations- 
informationen (alaAH, aliNI) fiir eine Zuordnung 60 
der jeweiligen Anforderung zu den vom Agent 
(AG) nachfolgend gesendeten Nachrichten 
(alNO) mit den Alarmdaten empfangen werden, 
und 

- von dem Manager (MAI, MA2) der Alarmda- 65 
tenabgleich abhangig von zumindest einem zum 
Agent (AG) gesendeten Parameter (par) gesteuert 
wird. 
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2. Verfahren nach Anspruch 1, bei dem von dem Ma- 
nager (MAI, MA2) der oder die Parameter (par) in je- 
der Anforderungsnachricht (repAA) zu dem Agent 
(AG) gesendet werden. 

3. Verfahren nach Anspruch 1, bei dem von dem Ma- 
nager (MAI, MA2) der oder die Parameter (par) in ei- 
ner den Anforderungsnachrichten (repAA) vorange- 
stellten Setznachricht (M-SET) zu dem Agent (AG) ge- 
sendet werden. 

4. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Parameterwert (relEN) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die von ausgewahlten Agenteinheiten 
stammen. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Parameterwert (relPS) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, fiir die eine Dringlichkeit angenommen 
wird. 

6. Verfahren nach Anspruch 5, bei dem von dem Ma- 
nager (MAI, MA2) ein zusatzlicher Parameterwert 
(priPS) benutzt wird, anhand dessen der Agent (AG) 
beim Senden eine Priorisierung der angeforderten 
Alarme nach deren Dringlichkeit vornimmt. 

7. Verfahren nach Anspruch 6, bei dem der Agent 
(AG) die Priorisierung der zu dem Manager (MAI, 
MA2) zu ubertragenden Alarme nach unterschiedli- 
chen Dringlichkeitswerten (cri, maj, min, war) vor- 
nimmt. 

8. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Parameterwert (relTT) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die innerhalb eines durch einen Anfangs- 
zeitpunkt (inst) und einen Endzeitpunkt (inen) definier- 
ten Zeitintervalls entstehen. 

9. Verfahren nach einem der vorhergehenden Anspru- 
che, bei dem von dem Manager (MAI, MA2) ein zu- 
satzlicher Parameterwert (priDT) benutzt wird, anhand 
dessen der Agent (AG) beim Senden eine Priorisierung 
der Alarme nach dem Entstehungszeitpunkt (evT) der 
Alarme vornimmt. 

10. Verfahren nach Anspruch 9, bei dem von dem 
Agent. (AG) die Alarmdaten der Alarme mit den alte- 
sten Entstehungszeitpunkten (evT) zuerst und die 
Alarmdaten der Alarme mit den jungsten Entstehungs- 
zeitpunkten (evT) zuletzt bereitgestellt und gesendet 
werden. 

11. Verfahren nach Anspruch 9 oder 10, bei dem von 
dem Agent (AG) die Alarmdaten der Alarme mit kriti- 
scher Dringlichkeit, bei der die Funktionalitat als nicht 
mehr gegeben angenommen wird, zuerst und die 
Alarmdaten der Alarme mit unkritischer Dringlichkeit, 
bei der die Funktionalitat als noch gegeben angenom- 
men wird, zuletzt bereitgestellt und gesendet werden. 

12. Kommunikationssystem zur Behandlung von 
Alarmen durch ein mehrere Managementebenen (A, B, 
C) aufweisendes Managementnetz, wobei fiir einen 
Alarmdatenabgleich zwischen einem Agent (AG) einer 
Managementebene (z. B. B) und zumindest einem Ma- 
nager (MAI, MA2) einer nachsthoheren Management- 
ebene (z. B. A) die Alarmdaten aktiver Alarme iibertra- 
gen werden, 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Senden einer oder mehrerer 
Anforderungsnachrichten (repAA) zum Ubermit- 
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leln der Alarmdaten an den Agent (OMC1), und 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Empfangen von Korrelati- 
onsinfonnahonen (alaAH, aliNT) fiir eine Zuord- 
nung der jeweiligen Anforderung zu den vom 5 
Agent (AG) nachfolgend gesendeten Nachrichten 
(alNO) mil den Alarmdaten, und 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur eine Steuerung des Alarmdaten- 
abgleich abhangig von zumindest einem zum 10 
Agent (AG) gesendeten Parameter (par). 

13. Kommunikationssystem nach Anspruch 12, bei 
dem die Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) den oder die Parameter (par) in jede An- 
forderungsnachricht (repAA) einfugen. 15 

14. Kommunikationssystem nach Anspruch 12, bei 
dem die Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) den oder die Parameter (par) in cine den 
Anforderungsnachrichten (repAA) vorangestellte, zu 
dem Agent (AG) gesendete Setznachricht (M-SET) 20 
einfugen. 

15. Kommunikationssystem nach einem der Ansprii- 
che 12 bis 14, bei dem von dem Manager (MAI, MA2) 
ein Parameter (par) mit einem Parameterwert (relEN) 
versehen ist, durch den vom Agent (AG) Alanne ange- 25 
fordert werden, die von ausgewahlten Agenteinheiten 
stammen. 

16. Kommunikationssystem nach einem der Anspru- 
che 12 bis 15, bei dem ein Parameter (par) von dem 
Manager (MAI, MA2) mit einem Parameterwert 30 
(relPS) versehen ist, durch-den vom Agent (AG) 
Alarme angefordert werden, fur die eine Dringlichkeit 
angenommen wird. 

17. Kommunikationssystem nach Anspruch 16, bei 
dem von dem Manager (MAI, MA2) ein zusatzlicher 35 
Parameterwert (priPS) benutzt ist, anhand dessen der 
Agent (AG) beim Senden eine Priorisierung der ange- 
forderten Alarme nach deren Dringlichkeit vornimmt. 

18. Kommunikationssystem nach einem der Ansprii- 
che 12 bis 17, bei dem ein Parameter (par) von dem 40 
Manager (MAI, MA2) nut einem Parameterwert 
(relH) versehen ist, durch den vom Agent (AG) 
Alarme angefordert werden, die innerhalb eines durch 
einen Anfangszeitpunkt (inst) und einen Endzeitpunkt 
(inen) definierten Zeitintervalls entstehen. 45 

19. Kommunikationssystem nach Anspruch 18, bei 
dem von dem Manager (MAI, MA2) ein zusatzlicher 
Parameterwert (priDT) benutzt ist, anhand dessen der 
Agent (AG) eine Priorisierung beim Senden der 
Alarme nach dem Entstehungszeitpunkt (evT) der 50 
Alarme vornimmt. 
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